Data-Driven Testing is a software testing approach in which the test logic remains the same while different sets of test data are supplied to the test. Instead of creating separate test cases for every input combination, a reusable test can execute multiple times using different data sets.
Data-driven testing is widely used in Selenium automation frameworks for testing login credentials, registration forms, search functionality, product information, user roles, checkout scenarios, validation rules, and many other application workflows.
In a Selenium TestNG framework, data-driven testing can be implemented using @DataProvider, Excel files, CSV files, JSON files, databases, configuration files, or other external data sources. TestNG can execute the same test method with each data set while Selenium WebDriver performs the browser interactions.
Course Resource: Selenium Training | Register for Course Demo
Data-driven testing is a testing methodology where test data is separated from the test script. The same automation script can be executed repeatedly using different input values and expected results.
For example, consider a login page. The login functionality remains the same, but the username and password combinations may change for every test execution.
| Username | Password | Expected Result |
|---|---|---|
| admin | admin123 | Login Successful |
| manager | manager123 | Login Successful |
| invalidUser | wrong123 | Login Failed |
| admin | wrong123 | Invalid Password |
The test workflow remains the same while the input data changes.
Modern applications contain many combinations of input values. Testing every combination manually or by creating separate automation scripts can result in duplicate code and maintenance problems.
The general flow of data-driven testing is:
Test Data Source
|
v
Data Reader / Data Provider
|
v
Test Method
|
v
Selenium WebDriver
|
v
Application
|
v
Actual Result
|
v
Compare with Expected Result
|
v
Pass / Fail
|
v
Test Report
One of the most important concepts in data-driven testing is separating the test logic from the test data.
Test Logic defines how the test should execute. Test Data defines which values should be used during execution.
| Test Logic | Test Data |
|---|---|
| Open login page | Application URL |
| Enter username | admin |
| Enter password | admin123 |
| Click login | Login button locator |
| Verify result | Expected Dashboard title |
The logic can remain unchanged while the test data can contain many different values.
TestNG provides the @DataProvider annotation for implementing data-driven testing. A Data Provider supplies multiple sets of data to a test method.
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;
public class LoginTest {
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"admin", "admin123"},
{"manager", "manager123"},
{"employee", "employee123"}
};
}
@Test(dataProvider = "loginData")
public void loginTest(String username, String password) {
System.out.println("Username: " + username);
System.out.println("Password: " + password);
}
}
Here, the test method executes once for every row returned by the Data Provider.
TestNG Data Providers commonly return an Object[][]. The first dimension represents the rows and the second dimension represents the values supplied to the test method.
return new Object[][] {
{"John", "India"},
{"David", "USA"},
{"Robert", "UK"}
};
| Execution | Value 1 | Value 2 |
|---|---|---|
| 1 | John | India |
| 2 | David | USA |
| 3 | Robert | UK |
Each row represents one test execution, while each column represents one parameter.
Selenium WebDriver can use data-driven testing to execute the same browser workflow with different input values.
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;
public class LoginTest {
WebDriver driver;
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"admin", "admin123"},
{"manager", "manager123"},
{"employee", "employee123"}
};
}
@Test(dataProvider = "loginData")
public void loginTest(String username, String password) {
driver = new ChromeDriver();
driver.get("https://example.com/login");
driver.findElement(By.id("username"))
.sendKeys(username);
driver.findElement(By.id("password"))
.sendKeys(password);
driver.findElement(By.id("loginButton"))
.click();
}
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}
The browser workflow is identical for every execution, but the username and password values change.
Data-driven testing is especially useful for combining positive and negative scenarios in one reusable test structure.
@DataProvider(name = "loginScenarios")
public Object[][] loginScenarios() {
return new Object[][] {
{"admin", "admin123", "Dashboard"},
{"invalidUser", "admin123", "Invalid Username"},
{"admin", "wrong123", "Invalid Password"},
{"", "", "Required Fields"}
};
}
@Test(dataProvider = "loginScenarios")
public void loginValidationTest(
String username,
String password,
String expectedResult) {
System.out.println(
username + " | " + password + " | " + expectedResult
);
}
Login testing is one of the most common applications of data-driven testing because applications typically require many combinations of usernames, passwords, account states, and expected outcomes.
| Scenario | Username | Password | Expected Result |
|---|---|---|---|
| Valid Login | admin | admin123 | Dashboard |
| Invalid Username | invalid | admin123 | Error |
| Invalid Password | admin | wrong123 | Error |
| Empty Credentials | Empty | Empty | Validation Message |
Registration forms commonly contain multiple fields such as name, email, mobile number, password, and address. A data-driven framework can execute the same registration workflow with multiple records.
@DataProvider(name = "registrationData")
public Object[][] registrationData() {
return new Object[][] {
{"John", "[email protected]", "9876543210"},
{"David", "[email protected]", "9876543211"},
{"Robert", "[email protected]", "9876543212"}
};
}
@Test(dataProvider = "registrationData")
public void registrationTest(
String name,
String email,
String mobile) {
System.out.println(name);
System.out.println(email);
System.out.println(mobile);
}
Search functionality can be tested with multiple keywords using the same automation method.
@DataProvider(name = "searchData")
public Object[][] searchData() {
return new Object[][] {
{"Laptop"},
{"Mobile"},
{"Headphones"},
{"Keyboard"},
{"Mouse"}
};
}
@Test(dataProvider = "searchData")
public void searchTest(String keyword) {
System.out.println("Searching: " + keyword);
}
E-commerce applications provide many opportunities for data-driven testing. Products, quantities, categories, discount codes, payment methods, and shipping details can all be tested using multiple data sets.
@DataProvider(name = "productData")
public Object[][] productData() {
return new Object[][] {
{"Laptop", 1},
{"Mobile", 2},
{"Headphones", 3},
{"Keyboard", 1}
};
}
@Test(dataProvider = "productData")
public void productTest(String product, int quantity) {
System.out.println(product + " - " + quantity);
}
Expected results should often be included with input data. This allows the same test to validate different outcomes.
@DataProvider(name = "calculatorData")
public Object[][] calculatorData() {
return new Object[][] {
{10, 20, 30},
{5, 5, 10},
{100, 50, 150}
};
}
@Test(dataProvider = "calculatorData")
public void additionTest(int a, int b, int expected) {
int actual = a + b;
Assert.assertEquals(actual, expected);
}
Assertions compare the actual result generated by the application with the expected result supplied by the test data.
@DataProvider(name = "additionData")
public Object[][] additionData() {
return new Object[][] {
{10, 20, 30},
{5, 5, 10},
{100, 25, 125}
};
}
@Test(dataProvider = "additionData")
public void additionTest(int a, int b, int expected) {
int actual = a + b;
Assert.assertEquals(actual, expected);
}
This approach makes the expected result part of the data set rather than hard-coding it separately inside every test.
Data-driven frameworks do not have to keep all data directly inside Java classes. Test data can be maintained in external sources.
Excel is commonly used for managing structured test data. In Java-based Selenium frameworks, Apache POI can be used to read Excel workbooks.
@DataProvider(name = "excelData")
public Object[][] excelData() {
// Excel reading logic can be implemented here.
return new Object[][] {
{"user1", "pass1"},
{"user2", "pass2"},
{"user3", "pass3"}
};
}
A production framework can read rows dynamically and convert each row into a Data Provider data set.
CSV files are simple and lightweight sources for external test data.
@DataProvider(name = "csvData")
public Object[][] csvData() {
// CSV reading logic can be implemented here.
return new Object[][] {
{"John", "[email protected]"},
{"David", "[email protected]"}
};
}
JSON is frequently used in modern automation frameworks, especially where UI automation and API testing are combined.
@DataProvider(name = "jsonData")
public Object[][] jsonData() {
return new Object[][] {
{"Chrome", "https://example.com"},
{"Firefox", "https://example.com"}
};
}
Large applications may store test data in databases. A framework can execute a query, retrieve records, convert them into test-data objects, and pass them to the test method.
@DataProvider(name = "databaseData")
public Object[][] databaseData() {
// Database connection and query logic
// can be implemented here.
return new Object[][] {
{"user1", "active"},
{"user2", "inactive"}
};
}
Data-driven testing works effectively with the Page Object Model (POM). The Data Provider supplies the test data, while Page Classes contain the Selenium interaction logic.
Data Provider
|
v
Test Method
|
v
Page Object
|
v
WebDriver
|
v
Application
This separation improves maintainability because test data and page interaction logic are not mixed unnecessarily.
public class LoginPage {
WebDriver driver;
By username = By.id("username");
By password = By.id("password");
By loginButton = By.id("loginButton");
public LoginPage(WebDriver driver) {
this.driver = driver;
}
public void login(String user, String pass) {
driver.findElement(username).sendKeys(user);
driver.findElement(password).sendKeys(pass);
driver.findElement(loginButton).click();
}
}
The test class can then use a Data Provider to supply multiple login combinations.
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"admin", "admin123"},
{"manager", "manager123"},
{"employee", "employee123"}
};
}
@Test(dataProvider = "loginData")
public void loginTest(String username, String password) {
loginPage.login(username, password);
}
Data-driven testing and parameterization are related concepts, but they are not always identical.
| Concept | Purpose |
|---|---|
| Parameterization | Allows values to be supplied dynamically to tests. |
| Data-Driven Testing | Executes reusable test logic against multiple data sets. |
| Data Provider | A TestNG mechanism for supplying multiple data sets. |
| External Data Source | Stores test data outside the test code. |
| Hard-Coded Testing | Data-Driven Testing |
|---|---|
| Data is directly written inside test logic. | Data is separated from test logic. |
| More duplicate code may be required. | Same test can process multiple data sets. |
| Maintenance becomes difficult as data grows. | Data can be managed independently. |
| Limited scalability. | Better scalability. |
| Adding scenarios may require additional code. | Additional rows can often be added without changing the core test. |
Data-driven testing is the overall testing approach, while a Data Provider is one mechanism used to implement that approach in TestNG.
Data-Driven Testing
|
+---- TestNG DataProvider
|
+---- Excel
|
+---- CSV
|
+---- JSON
|
+---- Database
|
+---- API
|
+---- Other Test Data Sources
Because TestNG Data Providers commonly use Object[][], different compatible Java data types can be supplied.
@DataProvider(name = "mixedData")
public Object[][] mixedData() {
return new Object[][] {
{"John", 25, true},
{"David", 30, false},
{"Robert", 28, true}
};
}
@Test(dataProvider = "mixedData")
public void mixedDataTest(
String name,
int age,
boolean active) {
System.out.println(name);
System.out.println(age);
System.out.println(active);
}
Applications often contain different roles such as Admin, Manager, Employee, and Customer. Each role may have different permissions and workflows.
@DataProvider(name = "roles")
public Object[][] roles() {
return new Object[][] {
{"Admin"},
{"Manager"},
{"Employee"},
{"Customer"}
};
}
@Test(dataProvider = "roles")
public void roleTest(String role) {
System.out.println("Testing role: " + role);
}
Browser names can also be supplied as test data when the framework is designed to create the corresponding WebDriver instance.
@DataProvider(name = "browsers")
public Object[][] browsers() {
return new Object[][] {
{"chrome"},
{"firefox"},
{"edge"}
};
}
@Test(dataProvider = "browsers")
public void browserTest(String browser) {
System.out.println("Running on: " + browser);
}
In a real framework, the browser value can be passed to a Driver Factory that creates the required WebDriver.
Test environments such as QA, staging, and other controlled environments can be represented as test data.
@DataProvider(name = "environments")
public Object[][] environments() {
return new Object[][] {
{"QA", "https://qa.example.com"},
{"Stage", "https://stage.example.com"}
};
}
@Test(dataProvider = "environments")
public void environmentTest(
String environment,
String url) {
System.out.println(environment + " : " + url);
}
Environment configuration should be managed carefully, particularly when production systems or credentials are involved.
@DataProvider(name = "filters")
public Object[][] filters() {
return new Object[][] {
{"Laptop", "Electronics"},
{"Shoes", "Fashion"},
{"Book", "Books"}
};
}
@Test(dataProvider = "filters")
public void filterTest(
String keyword,
String category) {
System.out.println(keyword);
System.out.println(category);
}
The same test-data concept can be used across API and UI testing. For example, product information can be supplied to an API test for validation and then used in a UI test for verification.
Test Data
|
+---- API Test
|
+---- UI Test
|
+---- Database Validation
|
+---- Report
This approach can help maintain consistent test scenarios across different testing layers.
Regression testing is an important use case for data-driven automation. The same functionality can be validated using many combinations of input values after application changes.
For example, a search regression test can use different keywords, categories, filters, sorting options, and expected results without creating a separate automation method for every combination.
Data-driven testing can be used to validate boundary conditions.
| Input Type | Example Test Data |
|---|---|
| Minimum value | 1 |
| Below minimum | 0 |
| Maximum value | 100 |
| Above maximum | 101 |
| Empty value | "" |
| Null value | null |
This allows the same validation test to check multiple boundary conditions.
Equivalence partitioning divides input data into groups that are expected to behave similarly. Data-driven testing can provide representative values from each group.
For example, if an application accepts an age between 18 and 60:
Applications should also be tested with empty and missing values where applicable.
@DataProvider(name = "validationData")
public Object[][] validationData() {
return new Object[][] {
{"John"},
{""},
{" "},
{null}
};
}
@Test(dataProvider = "validationData")
public void validationTest(String value) {
System.out.println("Testing value: " + value);
}
The test should explicitly define the expected behavior for null, empty, and whitespace-only values.
The same Data Provider can be reused by multiple test methods when the data is logically applicable to both tests.
@DataProvider(name = "users")
public Object[][] users() {
return new Object[][] {
{"admin"},
{"manager"}
};
}
@Test(dataProvider = "users")
public void loginTest(String username) {
System.out.println("Login: " + username);
}
@Test(dataProvider = "users")
public void profileTest(String username) {
System.out.println("Profile: " + username);
}
In large automation frameworks, common Data Providers can be placed in separate classes.
public class LoginDataProvider {
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"admin", "admin123"},
{"manager", "manager123"}
};
}
}
The test can reference the external provider:
@Test(
dataProvider = "loginData",
dataProviderClass = LoginDataProvider.class
)
public void loginTest(
String username,
String password) {
System.out.println(username);
}
TestNG Data Providers can execute test invocations in parallel when configured appropriately.
@DataProvider(
name = "users",
parallel = true
)
public Object[][] users() {
return new Object[][] {
{"user1"},
{"user2"},
{"user3"},
{"user4"}
};
}
Parallel execution can reduce overall execution time, but the framework must be thread-safe.
When Selenium tests run in parallel, each concurrent test should generally use its own WebDriver instance or a properly designed thread-local driver strategy.
Data Provider
|
+---- Test Invocation 1 ---- WebDriver 1
|
+---- Test Invocation 2 ---- WebDriver 2
|
+---- Test Invocation 3 ---- WebDriver 3
|
+---- Test Invocation 4 ---- WebDriver 4
Sharing one mutable WebDriver instance across parallel tests can result in test interference and unreliable results.
Each Data Provider invocation can be represented as a separate test execution in TestNG reporting systems. This makes it possible to identify which particular data set passed or failed.
LoginTest
|
|-- admin / admin123 PASS
|-- manager / manager123 PASS
|-- invalid / wrong123 FAIL
Reports should provide enough information to identify failed scenarios without exposing sensitive information such as passwords or tokens.
Logging can help identify the data set being processed during test execution.
Test Started
Username: admin
Expected Result: Dashboard
Test Completed
Status: PASS
For sensitive test data, logs should mask passwords, tokens, API keys, and other confidential values.
Data-driven TestNG tests can be executed through Maven like other automated tests.
mvn testMaven can manage dependencies, build the project, execute TestNG tests, and integrate the test execution with CI/CD pipelines.
Data-driven testing is useful in continuous integration because the same automation suite can execute repeatedly against multiple test-data combinations.
Developer Commit
|
v
CI/CD Pipeline
|
v
Build
|
v
TestNG
|
v
Data Provider
|
v
Multiple Test Executions
|
v
Selenium WebDriver
|
v
Application
|
v
Test Report
Environment variables can be used for environment-specific or sensitive configuration. This helps prevent sensitive information from being embedded directly into test source code.
String username = System.getenv("TEST_USERNAME");
String password = System.getenv("TEST_PASSWORD");
The exact implementation depends on the CI/CD platform and security practices used by the project.
Passwords, API keys, access tokens, private URLs, and other secrets should not normally be stored as plain text in source-controlled test-data files.
| Data Source | Typical Use |
|---|---|
| Java Object[][] | Small and static test data |
| Excel | Structured business test data |
| CSV | Simple tabular data |
| JSON | Structured modern application/API data |
| Database | Large or dynamically retrieved data |
| Properties | Configuration values |
| Environment Variables | Environment-specific or sensitive configuration |
| API | Dynamically generated or service-based data |
Test Data
|
+-------------+-------------+
| | |
Excel JSON DB
| | |
+-------------+-------------+
|
v
Data Reader
|
v
Data Provider
|
v
Test Method
|
v
Page Object
|
v
Selenium WebDriver
|
v
Application
|
v
Assertion
|
v
Report
The following example demonstrates a basic data-driven Selenium login test using TestNG.
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.Assert;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;
public class LoginTest {
WebDriver driver;
@BeforeMethod
public void setup() {
driver = new ChromeDriver();
driver.manage().window().maximize();
driver.get("https://example.com/login");
}
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"admin", "admin123"},
{"manager", "manager123"},
{"employee", "employee123"}
};
}
@Test(dataProvider = "loginData")
public void loginTest(
String username,
String password) {
driver.findElement(By.id("username"))
.sendKeys(username);
driver.findElement(By.id("password"))
.sendKeys(password);
driver.findElement(By.id("loginButton"))
.click();
Assert.assertTrue(
driver.getTitle().contains("Dashboard")
);
}
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}
A scalable Selenium data-driven framework can separate tests, pages, data providers, utilities, and external test data.
src
|-- test
|-- java
|-- tests
| |-- LoginTest.java
| |-- SearchTest.java
| |-- RegistrationTest.java
|
|-- pages
| |-- LoginPage.java
| |-- SearchPage.java
| |-- RegistrationPage.java
|
|-- data
| |-- LoginDataProvider.java
| |-- SearchDataProvider.java
| |-- RegistrationDataProvider.java
|
|-- utilities
| |-- DriverFactory.java
| |-- ExcelReader.java
| |-- JsonReader.java
| |-- ConfigReader.java
|
|-- reports
|-- ReportManager.java
test-data
|-- login.xlsx
|-- search.csv
|-- users.json
Data-driven testing is appropriate when the same functionality needs to be tested with multiple meaningful input combinations.
Not every test requires a data-driven architecture. A simple one-time scenario with one fixed input may not need a Data Provider or external test-data framework.
Using unnecessary abstraction can make a small test more complicated than required. The testing framework should use the simplest structure that provides the required maintainability and coverage.
Data-driven testing is an approach where the same test logic is executed with multiple sets of test data.
It allows the same Selenium workflow to be executed against different input values without creating duplicate test methods.
A Data Provider is a TestNG mechanism that supplies multiple data sets to a test method.
The @DataProvider annotation is used.
It commonly represents multiple rows and columns of test data, where each row is supplied to one test invocation.
Yes. Each row can contain multiple values corresponding to the parameters of the test method.
Yes. Java libraries such as Apache POI can be used to read Excel data and provide it to automated tests.
Yes. CSV files can be read and converted into data sets for automated tests.
Yes. JSON is frequently used as a structured source of test data, particularly in API and modern automation frameworks.
Yes. A framework can query a database and convert returned records into test-data sets.
Parameterization is the mechanism of supplying values dynamically, while data-driven testing focuses on executing reusable test logic against multiple data sets.
Common uses include login, registration, search, checkout, product, role, form, validation, regression, and boundary testing.
Yes. TestNG Data Providers can be configured for parallel execution when the automation framework is thread-safe.
Parallel test executions should not interfere with one another. Selenium WebDriver instances and mutable test state should be isolated appropriately.
Yes. The Data Provider can supply test data while Page Objects handle page interactions.
Plain-text credentials should generally be avoided in source-controlled test-data files. Appropriate secret-management mechanisms should be used.
Reports and logs can include safe identifiers such as usernames, scenario names, or test-data IDs without exposing sensitive values.
The main advantage is reusing the same test logic for multiple data combinations.
Common mistakes include incorrect parameter mapping, poor test-data organization, sensitive-data exposure, and unsafe WebDriver sharing during parallel execution.
It allows existing automation workflows to be executed with many different inputs after application changes, increasing the range of scenarios covered by the regression suite.
| Concept | Description |
|---|---|
| Data-Driven Testing | Executing the same test logic with different data sets. |
| @DataProvider | TestNG annotation for supplying multiple data sets. |
| Object[][] | Common structure for rows and columns of test data. |
| External Data | Test data stored outside the Java test logic. |
| Excel | Common structured source for test data. |
| CSV | Simple tabular test-data source. |
| JSON | Structured data source commonly used in modern applications. |
| Database | Dynamic source for retrieving test data. |
| POM | Separates Selenium page interaction logic from tests. |
| Assertions | Compare actual results with expected results. |
| Parallel Execution | Allows independent data-driven invocations to execute concurrently. |
| Test Reports | Provide execution results and help identify failed scenarios. |
Consider an e-commerce website where a QA engineer needs to verify product search for multiple products.
@DataProvider(name = "products")
public Object[][] products() {
return new Object[][] {
{"Laptop"},
{"Mobile"},
{"Tablet"},
{"Headphones"},
{"Keyboard"}
};
}
@Test(dataProvider = "products")
public void productSearchTest(String product) {
driver.findElement(By.id("search"))
.clear();
driver.findElement(By.id("search"))
.sendKeys(product);
driver.findElement(By.id("searchButton"))
.click();
System.out.println(
"Searching product: " + product
);
}
Instead of creating five separate test methods, one reusable method handles all five product searches.
Test Data
|
+--------------+--------------+
| | |
Excel JSON DB
| | |
+--------------+--------------+
|
v
Data Reader
|
v
Data Provider
|
v
Test Method
|
v
Page Object
|
v
Selenium WebDriver
|
v
Application
|
v
Assertion
|
v
Report
Data-driven testing is a powerful automation approach that separates test data from test logic and allows the same test workflow to execute against multiple input combinations.
In Selenium and TestNG frameworks, data-driven testing can be implemented through @DataProvider, Excel, CSV, JSON, databases, APIs, and other external data sources.
It is particularly useful for login, registration, search, product, checkout, role-based, validation, boundary, regression, and cross-browser testing scenarios.
A well-designed data-driven framework should keep test data organized, separate Selenium interaction logic through Page Objects, use assertions for validation, protect sensitive information, identify failed data sets clearly, and maintain thread safety when parallel execution is used.
Learn Selenium automation, TestNG, data-driven testing, automation frameworks, reporting, and related QA concepts through the following resources:
Final Takeaway: Data-driven testing makes Selenium automation more reusable, scalable, and maintainable by allowing one test workflow to validate many different data combinations. When combined with TestNG Data Providers, Page Object Model, external data sources, assertions, reporting, Maven, and CI/CD, it becomes an important part of a structured Selenium automation framework.
